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ABSTRACT 



The Telecommunications Emergency Decision Support System (TEDSS) was developed 
by the National Communications System (NCS) to assist in the management of national 
communication assets during times of emergency. TEDSS is currently approaching the end of 
its system life, and is only marginally capable of meeting existing and future requirements. 

The personal computer-based system uses a structured menu-oriented interface developed 
within an INGRES database management system application environment. This system 
provides predefined queries and menus which minimize the amount of decision support 
provided for emergency management. 

This thesis reviews the current operational capabilities of TEDSS and the emergency 
decision making environment in which it operates. It proposes a conceptual shift of TEDSS 
from its current textually-oriented information system to a graphically-oriented Tactical 
Decision Aid (TDA). The proposed system would employ a Graphical User Interface (GUI) 
providing a standard interface to a Geographical Information System (GIS). The GIS would 
provide a map-based environment in which the user manipulates data and models. Software 
and hardware issues relating to the development of a TDA-based TEDSS are discussed. 
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I. INTRODUCTION 



The Telecommunications Emergency Decision Support System (TEDSS) is an 
automation tool which has been developed by the Federal Government to assist in the 
management of communications assets during times of national emergencies. The system 
was "designed to provide timely, accurate, and relevant information concerning 
telecommunications capabilities." (Short and Bockenek, 1989, p. 1). It supports the 
National Communications System (NCS) Headquarters and Regional components 
Emergency Management Teams (EMT) tasked with maintaining viable functioning 
communication links across the country during times of emergency. The existing system 
provides limited support for the current mission in the form of a database-oriented system. 
The system provides data retrieval but very little decision support. As the amount of 
electronic data increases and our dependence on the ability to maintain those 
communications channels becomes more critical, TEDSS, as currently configured, wiU be 
hard pressed to support the future effective management of restoring communications. 
(Short and Bockenek, 1989, p. 1) 

A. TEDSS OBJECTIVE 

The TEDSS is designed to assist in the management of three general types of 
communication problems: 

1 . Localized regional emergencies such as floods and other natural disasters. 
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2. Emergencies affecting multiple regions of the nation that require national-level 
coordination, e.g., Three Mile Island incident. 

3. Nationwide emergencies such as a potential nuclear attack. (Short and Bockenek, 
1989, p. 3) 

The NCS has originally separated TEDSS responsibilities into three operational 
domains: 

1. National Level - to enable the Office of the Manager, National Communication 
Services, to monitor, coordinate and control telecommunications resources during a 
national emergency. 

2. Regionally-Deployed Component - to aid in monitoring regional emergencies and 
coordinating actions affecting multiple regions of the nation. 

3. Regional-Level Component - to manage the information needed to resolve local 
emergencies without the direct involvement of the national level of NCS. (Booz, Allen 
and Hamilton, Deployment Plan, 1988, p. 2) 

Short and Bockenek’s thesis (1989) and the Booz, Allen and Hamilton’s 
Deployment Plan (1988) provide additional descriptions of the original delineation of 
component responsibilities. While the system initially was physically configured to match 
these three areas of responsibilities, the rapid development of inexpensive and more 
powerful computing hardware and software has blurred the distinctions between the 
national and regional systems. Presently the primary difference between the components 
is in administrative control of data update capabilities. It appears that the MicroVAX 
mini-computer which has served to manage the TEDSS regional/national databases is 
being phased out, and all TEDSS functions will be maintained on the deployable portable 
machine. 
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B. TEDSS GENEALOGY 



The NCS was directed by executive order to prepare plans and coordinate systems 
to establish and maintain communications during times of national emergencies 
(Reinman, 1984, p. 12). After a national telecommunications exercise was conducted in 
1982, subsequent review of the exercise identified a need for an automated decision 
support system to assist in the management and tracking of telecommunications assets 
(Short and Bockenek, 1989, p. 1). In an effort to manage the information about various 
communications assets and points of contact a microcomputer-based Fly Away 
Management Information System (FAMIS) was developed in 1983 (Lyons, 1986, p. 2). 

The FAMIS system, while an improvement in emergency information management, 
was limited in providing effective support in times of crisis. The NCS contracted for 
several studies and development efforts to move the FAMIS system to a mini-computer 
and micro-computer implementation. This revised implementation of FAMIS was called 
the Emergency Preparedness Management Information System (EPMIS). The EPMIS 
system reshaped the data management capabilities around a database management system 
and added some additional functionality to FAMIS. However it stUl maintained a 
structured menu-oriented system and a restrictive data manipulation scheme. 



'In 1990, the system name became Telecommunications Emergency Decision Support 
System (TEDSS), however the system was originally developed under the name of the 
Fly Away Management Information System (FAMIS) which evolved into the Emergency 
Preparedness Management Information System (EPMIS). During this thesis, all 
references to the system will be as TEDSS. 
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During a series of enhancements to EPMIS, the system name was eventually 
changed to the Telecommunications Emergency Decision Support System (TEDSS). The 
current version of TEDSS, version 6.0, provides some graphical presentation tools but still 
maintains a primarily text-based information system. Chapter II will address the present 
functional capability of the TEDSS system in more detail. 

C. SCOPE OF THESIS 

TEDSS is approaching a crossroads in its system life. The current implementation 
has several limitations that are impeding its present operation and may complicate future 
enhancements as the system continues to evolve. This thesis will review the current state 
of the TEDSS system and its present functional capabilities. It wiU then address relevant 
issues involving a complete reassessment of the ctirrent TEDSS implementation. The 
purpose of the thesis is to provide a revised framework for the TEDSS system hardware 
and software architecture. The objective is to envision an enhanced platform which not 
only supports emergency management decisions better today, but wiU also provide a 
suitable migration path for TEDSS growth into the future. 

D. METHODOLOGY 

The NCS believes that TEDSS currently possesses the basic functionality required 
to support its mission. However, TEDSS performance, operational costs, and 
expendability are considered lacking. This thesis will be divided into two sections. The 
first wiU evaluate the existing system and how it supports the decision making process, 
and wUl include; 
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1. A review of the current TEDSS system to determine the current functions it performs, 
and 

2. An investigation of the emergency and tactical decision making environment, and 
development of a proposed system to overcome existing deficiencies in TEDSS. 

The second section will detail the proposed system to enhance TEDSS abUity to 
support the decision making process, and will include: 

3. A discussion of the implications of the proposed system, and how it wUl affect the 
TEDSS decision making environment and its users, 

4. An explanation of the primary components’ utilization in the proposed system, and 

5. Identification of critical developmental issues that must be addressed prior to 
implementation of future TEDSS revisions. 

E. THESIS STRUCTURE 

The remainder of the thesis wUl be structured as follows. 

Chapter II analyzes and reviews the current TEDSS hardware and software 
configuration. 

Chapter in analyzes TEDSS in the context of tactical decision environments and 
systems to support NCS decision making and proposes a TEDSS block architecture 
consistent with this concept. 

Chapter IV discusses the capabilities and implications of utilizing a Graphic User 
Interface (GUI) and Geographic Information System (GIS) as integral components of 
TEDSS. 
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Chapter V discusses software considerations in the future development of TEDSS 
to both decrease system maintenance cost and provide for a baseline system that wiU 
serve as an expanding platform for emerging technology. 

Chapter VI addresses the unique operational issues and requirements for the TEDSS, 
and the tradeoffs that should be addressed in future TEDSS hardware components. 

Chapter VII concludes the thesis by reviewing the proposed system, summarizing 
issues and discussing the advantages of the proposed system to support the evolution of 
TEDSS into the next century. 

F. LIMITATIONS 

The primary limitation to this thesis has been determining the present capabilities 
of TEDSS and the lack of current or detailed documentation of the system. During my 
site visit to NCS, the current model of TEDSS was not available for review because of 
security restrictions. An earlier beta version was available which provided a basic 
understanding of the system and its user interface but did not implement the Mapinfo 
interface. Much of the information on the use and capabilities of TEDSS was determined 
by several conversations with Major Fran School at NCS, including a basic understanding 
of the TEDSS tactical decision making environment. 
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II. TEDSS ENVIRONMENT 



The Telecommunications Emergency Decision Support System (TEDSS) is designed 
to support the NCS in time of crisis, and like most information systems, is evolutionary 
in natvure. The original system designed in the early 1980’s would have been considered 
"state of the art" for that time. However, rapid advances in computing technology and 
software developments have overshadowed the relatively limited range of functions which 
TEDSS currently performs. The present TEDSS, version 6.0, is significantly more 
powerful than its original implementation in terms of raw computing power, but the 
system’s functional capabilities and data access tools have not changed significantly. 

The current TEDSS is composed of two separate hardware platforms: the national 
and regional components which operate on MicroVAX II mini-computers, and the 
deployable component which operates on portable personal computer (PC). Previously, 
the TEDSS database had been maintained on the national component’s MicroVAX which 
updated the regional components which in turn updated the deployable component’s 
database. It appears that the functions of the MicroVAX are being transferred to the 
deployable component, and future versions of the TEDSS (beyond version 6.0) will no 
longer utilize the MicroVAX. 

A. HARDWARE 

The TEDSS requirement of portability has been a limiting factor in some decisions. 
The present system utilizes an Intel 80386-based portable PC which requires 110 volts 
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AC to operate. The basic system contains a gas-plasma style display and detachable 
keyboard. The initial system goal was to provide all required capabilities in a single unit. 
However, during TEDSS software development, a larger fixed disk storage capacity was 
required than could be internally mounted. To provide enough storage capacity an 
external removable cartridge hard disk storing 200 megabytes of information was 
installed. The removable cartridge allows the replacement or removal of all software 
from the TEDSS system in a few minutes. 

Beginning with version 6.0 of TEDSS, a DOS-based mapping package and color 
video graphics adapter (VGA) monitor were added to the system. It is assumed that the 
monitor was added to provide better image resolution and easier viewing, and not because 
the mapping package was unable to support the system’s internal gas plasma display. 

B. SOFTWARE 

The TEDSS deployable software suite is composed of three distinct component 
programs, in addition to the custom developed software: 

1. The Operating System: Interactive 386/ix UNIX. Interactive’s UNIX supports all 
standard UNIX functions and the disk operating system (DOS) for the personal 
computer operating under UNIX, wherein DOS applications run as processes under the 
UNIX operating system. 

2. Database Management System: INGRES relational database management system for 
the UNIX operating system. (Version 5.0/06). 

3. Geographic Information System: Mapinfo operating in the DOS environment. The 
Mapinfo package wUl display information onto regional maps and plot points stored 
in an ASCII file or external database. 
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The menuing system and other software procedures were developed using INGRES 
application development tools and the C programming language. The use of a proprietary 
package (INGRES) to develop and control the user interface has unnecessarily constrained 
options to update or revise TEDSS. As TEDSS is currently implemented, it can not 
operate unless INGRES is present. 

C. PRESENT USER INTERFACE 

The TEDSS system relies on a menu-based interface which allows the user to select 
from different views of the information within the database. Figure 1 shows the TEDSS 
main menu as displayed in the Booz, Allen and Hamilton Regional Component Software 
Design (1989)^. Once the data desired is selected, some, but not all, menu screens 
provide an option to display the selected information graphically utilizing the Mapinfo 
package. The data selected in the menu is written to an ASCII text file, and then 
displayed on a map of the area. 

Figure 2 provides a graphical view of the overall menu structure. The following 
is a short summary of the menu options (Booz, Allen and Hamilton Deployment Plan, 

1988, p. 16). 

1. Emergency Activation Procedures 

The Emergency Activation Procedures menu item allows the user to select 
from another menu to retrieve Emergency Action Documents, determine and track the 
Emergency State of the Nation, and generate a regional emergency recall list. 

^This is the latest known hardcopy documentation on the TEDSS menu schema. 
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TEDSS 
Main Menu 



1. Emergency Activation Procedures 

2 . Emergency Points of Contact 

3. Resource Management 

4. Damage Assessment 

5. Service Requests 

6. Communications 

7. Exit 

Enter Selection : 

Help (FI) 

Figure 1 TEDSS Main menu screen 

2. Emergency Points of Contact 

The Emergency Points of Contact menu item allows the user to update or 
retrieve from an address and telephone database of critical personnel. 

3. Resource Management 

Resource Management is the primary module in the current TEDSS system 
allowing the user to enter, change the status of, or monitor several different resoiuce 
conditions. There are two menu items: resource entry and monitor resources. 
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Emergency 


j— Emergency Activation Documents (EAD) 






4— Emergency State of the Nation 




Procedures 


L— Emergency Recall List 




Emergency 








— Points of ■ ■ 


—— Queries 




Contact 






Main _ 


Resource 


r— Enter Resources 


Menu 


Management 


Monitor Resources 




__ Damage 


r— Enter Damage 




Assessment 


4-— Execute Damage 






Monitor Damage 




Service 


r— Service Requests 




Requests 


Facility Requests 




— Communications 




Mail 






— Telephone 






— Messages 



Figure 2 TEDSS menu structure 



a. Resource Entry 

Additional changes to existing resources are manually entered via a 
preprogrammed form. There are seven types of resources presently monitored: 
personnel, networks, nodes, links, operations centers, asset centers, and assets. The 
following list is a short description of the resources monitored and a partial list of the 
information stored within the database. Short and Bockenek (1989), and Booz, Allen and 
Hamilton’s two reports Regional Component Software Design (1989) and Deployment 
Plan (1988) provide additional information concerning resource definition, database design 
and screen content. 
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1. Personnel - status, primary and emergency locations.^ 

2. Networks - network name, network identification (ID), description, control center 
location and point of contact (POC). 

3. Nodes - nodes within a network, including network ID, description, location, and POC. 

4. Links - the links between two nodes on a network, including node Ids, description, 
priority and carrier. 

5. Operation Centers - information on the operation center which controls a network, 
including network ID, description, status, and POC. 

6. Assets - communication asset including a description, status, location, priority, 
mobility, capabilities and POC. 

7. Asset Center - the asset center assigned to a resource location including name, 
description, location, status and POC. 

b. Monitor Resources 

This menu item allows users to queiy the database to determine the status 
of various resources according to predefined criteria. Users may query by network, node, 
location, status and other key fields. However they are restricted by the menu as to 
which selection criteria may be applied to each resource. The queries allow the user to 
select according to several key areas but do not allow any boolean search criteria. 

As currently implemented, a boolean search to determine only the nodes 
within the states of California and Nevada is not possible. TEDSS as currently 
configured only allows selections on the state, region, or national geographical areas. To 
implement this search would require selecting all nodes in the region, and then manually 

^Location unless otherwise stated is stored both as a street address and geographic 
location using latitude and longitude in degrees, minutes and seconds. 
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culling the data required. However, if the desired states were not co-located in the region, 
the user would be required to make two separate queries and combine the results or 
retrieve all nodes within the national region, and again, manually compile the results. 

4. DAMAGE ASSESSMENT 

This menu selection allows the user to input observed damage information 
from natural or man-made sources, to execute simulations from an internal probabilistic 
model, and to monitor existing damage or review journaled damage. 

Presendy the damage assessment module is the only Decision Support System 
(DSS) component present in TEDSS to support the Emergency Management Team (EMT) 
in extending the data analysis capabilities. The model determines what facilities were 
most likely affected by a nuclear detonation. The model accepts information about the 
latitude and longitude, blast height, direction and other information about the detonation 
to define a rectangular or circular estimate of the affected areas. If the model is executed, 
a list of assets that may have been damaged is displayed. The user may then choose to 
Journal those sites which may have been affected for further investigation. These sites 
may then be recalled as required under the List Journaled Damage menu item. 

5. TELECOMMUNICATIONS REQUESTS 

This menu item allows the user to enter and display claims for 
telecommunications services and facilities requests. 

Service requests are created when an agency wishes service restored, or initiated 
in an emergency situation. Facility requests are generated when nodes and/or 
operating centers no longer provide vital communications. (Short and Bockenek, 
1989, p. 55) 
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All requests are reviewed by the EMT at the National/Regional Command Center 
(NCC/RCC). Then in accordance with the current Emergency State of the Nation and the 
relative importance of the agency making the claim, a priority for service restoration is 
assigned. After receiving a priority the request is forwarded to a service provider to 
effect the reconnection of services. As the emergency evolves, the telecommunications 
service priority (TSP) may change, which in turn may cause the service restoration order 
to change. This module also supports journaling of service requests, and allows for 
journal updates as requests are completed and services restored. 

6. COMMUNICATIONS 

This menu item facilitates a communication link between TEDSS users. The 
user enters a message to be mailed electronically to another user and initiates manually 
the dialing of the user’s telephone number. It does not apparently interface in any way 
with the TEDSS database. 

The current capabilities of TEDSS meet the basic needs of the EMT. 
However they provide little assistance in guiding, or assisting them in the decision making 
process. Additionally the menu structure does not allow much, if any, flexibility in data 
retrieval and presentation methods. The following chapter will review the emergency and 
tactical decision making environment and provide a different model of TEDSS to 
overcome some of the present deficiencies. 
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in. EMERGENCY AND TACTICAL DECISION MAKING 



The computer can assist human analysis of large quantities of data by translating 
data into more useful and manageable information. This chapter addresses the basic 
concepts of decision support and proposes a different concept of TEDSS as a Tactical 
Decision Aid (TDA) to support the Emergency Management Team (EMT). 

In making the relevant information available to operating public service personnel 
in a timely, interactive mode, the system will likely increase the power of decision 
makers to make appropriate decisions. (Comfort, 1985, p. 41) 

Decisions based on information provided by TEDSS, or any system being utilized 
for emergency management, are greatly hindered by the lack of rules about how the 
system will be utilized. Decision makers in emergency management "operate under the 
recurring problems caused by information overload," and where "environmental conditions 
are rapidly changing and dynamic" (Comfort, 1985, p. 41). 

When dispatched to an emergency situation, the National or Regional Emergency 
Management Team (NEMT or REMT), the National Communications Center (NCC) and 
the Federal Emergency Communications Center (FECC) personnel will be called upon to 
make resource decisions that could significantly affect resource allocation and the length 
of time until service is restored. While organized and structured service priority ranking 
systems such as the Telecommunications Service Priority (TSP) and Restoration Priority 
(RP) systems add structure to the chaos, unforeseen contingency situations will require 
local judgment as to the most efficient procedure for restoring service. (Booz, Allen and 
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Hamilton Technology Assessment Report I, 1990, p. 1) (Booz, Allen and Hamilton 
Integration Plan, 1989, p. 7) 

TEDSS current text-based approach to the entry, retrieval, and support of decision 
making are not conducive to making effective decisions. We believe that providing the 
EMT with the ability to obtain a more visual presentation of information and the ability 
to dynamically define the display of information wiU improve the users decision quality 
and speed. The tactical decision aid (TDA) wUl provide this support. 

A TDA will assist the EMT in collecting, correlating emd applying available data 
to improve decision speed and quality. A TDA wiU providing him with tools to assist 
in modeling data to provide information in the form that they desire, not a defined menu 
format. 

A. DECISION SUPPORT SYSTEMS (DSS) 

Decision support systems focus on supporting the decision making process rather 
than a system of information and reports. DSS "consist of three primary subsystems - a 
data base, a model base and the decision maker." (Sprague and Watson, 1983, p. 21). Of 
major importance is the effective management of the subsystems and the user interface. 

DSS are not ’intelligent’ in human terms, but rather are programmed to be smart 
assistants which present information in a useful form to support the decision making 
process. The computer’s assistance is most useful when handling a semi-structured task 
that has accepted methods of handling information, but whose methods may be either too 
time intensive or data intensive to be handled manually. Semi-structured tasks involve 
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data and the users’ intuition and judgment. DSS that support credit application approvals, 
inventory management and job scheduling are examples of tasks that have definable 
criteria. While the computer can determine results more efficiently than a human, it may 
require human judgment to compensate for variables that were not taken into account in 
the model. 

A DSS will identify relevant data attributes, choose an appropriate model to 
analyze, summarize, and present the information to the user using predefined knowledge 
rules. The user may accept or discard the DSS analysis and results in his final decision 
because of factors that are not available to the DSS. For example, a loan officer may 
approve a loan despite a DSS recommendation to the contrary because he knows of 
extenuating factors not included in the model of loan approvals. 

The term DSS has been used to describe a broad range of computer systems, from 
simple personal computer spreadsheets to complex financial planning tools. For the 
purposes of this paper, a DSS wiU be defined as: 

Interactive computer-based decision support systems are sets of data bases, 
models, and algorithms capable of solving operational, tactical, and strategic 
problems. (Andriole, 1989, pp. 226-227) 

Of primary importance to DSS, regardless of any definition, is effective dialogue 
management between the system and the decision maker. It is through an effective 
interface with the decision maker and integration of internal DSS subsystems that a DSS 
will become a useful tool for problem resolution. (Sprague and Watson, 1983, p. 21) The 
following sub-sections will describe the key subsystems in a DSS. 
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1. Model Management 

A model transforms data into information. A model is a careful description 
of a real system. Model Management is the method of selecting the most appropriate 
model of analyzing the data for presentation to the user. A model may range from a 
simple tabular summary to a complex statistical profile, and will normally provide a 
condensed appraisal of the relevant information. A model is not constrained to 
mathematical relations between data fields; it may also consist of knowledge in the form 
of rules which form a model of one or more person’s expertise. 

2. Data 

Data are the raw materials which drive the execution of models and 
knowledge bases. DSS often rely upon external databases to provide the storage, 
retrieval, and administration of data. 

3. Knowledge Base 

A knowledge base is a collection of facts stored as logic rules, heuristics, or 
algorithms which provide the DSS with "intelligence." Heuristics or "rules of thumb" are 
broad generalizations which have been determined to be accurate in shaping the 
presentation of information for decision making. A knowledge rule for credit approval 
might be "no credit will be approved if the applicant has declared bankruptcy," or "all 
credit cards must have less than ten percent of the credit limit used." 
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4. Dialogue Management or User Interface (UI) 

Dialogue Management or User Interface (UI) is the glue which holds the DSS 
components together; it is the porthole to the system. "From the users’ viewpoint the 
interface is the system and the main issue in design is how the system should appear to 
the user." (Keen, 1983, p. 171). 

The DSS must mimic or support the user’s efficient decision making process 
to be effective. Information or queries may be presented graphically, question and answer 
dialogue, or other methods maybe used. However, the system UI must be consistent with 
the users’ own method of problem solving. If the system violates that dictum, the user 
will become frustrated and confused, have more difficulty in using the system effectively, 
and ultimately wiU lose motivation to use the system. (Wagner, 1989, p. A-1) 

B. EXISTING DSS SUPPORT FOR TEDSS 

Presently the TEDSS has no internal DSS capabilities beyond the damage 
assessment model discussed in Chapter II. The Expert Telecommunications Resource 
Allocation Module (XTRAM) was a knowledge base developed to support the Resource 
Allocation Officer and Emergency Management Team (EMT) in prioritizing and 
managing resource allocation when using TEDSS. A prototype of XTRAM was 
developed on a different hardware platform, and it has not been determined when, or if, 
the conversion to the deployable version of TEDSS wiU be made. (Booz, Allen and 
Hamilton Deployment Plan, 1988, p. 15), (Booz, Allen and Hamilton Integration Plan, 
1989, p. 5) 
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Regardless of the future of XTRAM, it did demonstrate that TEDSS can utilize DSS 
capabilities. TEDSS should translate incoming data into information which the user can 
process to make the best possible decision at the time. It should also alert the EMT as 
the implications of previous decisions emerge and the situation changes. 

C. TACTICAL DECISION AIDS (TDA) 

A TDA can be considered as a special type of DSS which is organized to assimilate 
rapidly changing information to support the best possible decision in a limited time frame. 
Decisions are intended to ’satisfice’ rather than optimize in this kind of environment. 

TDAs differ from conventional DSSs in their utilization of dynamic situational 
information to support decisions that help secure a strategic objective. Tactical systems 
normally receive continuous streams of information from sensors; or other information 
systems to support their analysis models. The streams of data processed through TDA 
models provide real-time or near-real-time information to a tactical decision maker who 
continuously reacts to the implications of the changing data. 

Tactical DSSs are becoming more critical on the electronic battlefield as they 
provide operational units with the tools to process large amounts of incoming electronic 
data for real time battle management. The data may come in the form of pre-formatted 
messages, motion sensors, satellite downlinks, or numerous other electronic forms. 
Although TDAs are often associated with the military, they are useful for any 
organization requiring real-time or near real-time support for decisions. 
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TEDSS assists emergency management teams decisions in a real-time environment. 
However, unlike a military combat information center (CIC), decisions regarding 
incoming threats are normally required in tens of minutes versus minutes or seconds. 
This difference does not alter TEDSS requirements for real time information, but it does 
allow TEDSS more flexibility to evaluate multiple scenarios, and therefore, provide more 
effective resource allocation. 

Although TEDSS decisions are not as time critical as some military applications. 
If made incorrectly, they could nevertheless result in significantly increased amounts of 
service time lost, and materially affect the nation’s communications assets. The 
TEDSSAT)A concept would allow the "evaluation of alternative plans or concepts of 
operation,” and could warn the Emergency Management Team (EMT) of possible rule 
violations and encourage multiple ways of looking at solutions to the problem. (Andriole 
and others, 1991, p. 170). The extension of TEDSS to support the EMT in projecting the 
effect of the current decision will assist in making decisions. If future information 
indicates that the original assumptions made by the EMT were based on faulty 
information, the ’story’ or directions may be adjusted. 

D. TEDSS DECISION ENVIRONMENT 

The TEDSS emergency management environment can be viewed as primarily a 
Command and Control (C^) system dedicated to controlling and directing all available 
communication assets and to restoring telecommunications assets and communications 
links in order of greater national importance. The decisions required for restoring those 
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communications will rarely foUow a simple path. TEDSS should support those changes. 
Tactical decisions concerning resource management can be supported by a Tactical 
Decision Aid (TDA). The ability to model the results of related decisions over a period 
of time, or storyboard can be a powerful tool in decision support. (Andriole, 1985, 
p. 170) 

Designing an effective DSS or TDA for managing under emergency conditions is 
a significant challenge because of the iU-defined problems that must be addressed. 
Situations are likely to be changing rapidly, and data which is received from multiple 
untrained or unreliable sources must be evaluated on the basis of its accuracy and 
relevance. Additionally, critical decisions may be required within this dynamic 
environment that may have no correct answer. The EMT may be required to decide 
between restoring communication at several nearby sites or a distant site in which all have 
equal restoration priority. Suppose the closest sites will take longer to restore than the 
distant ones. In this scenario, which site will offer the most benefit? 

In addition to the marked increase in the complexity and rate of demands made 
upon the information processing capacity of the decision-makers under emergency 
conditions, the ability of human decision-makers to manage complexity tends to 
decrease under stress. (Comfort, 1985, p. 41) 

These counterproductive conditions of increased information processing 
requirements and reduced ability for processing may be partially controlled by training 
and simulations. TEDSS must provide a knowledge base of information and some form 
of interactive information manager to support the user in managing incoming data and to 
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"extend the capacity of human decision-makers operating under conditions of complexity 
and stress." (Comfort, 1985, p. 41). 

The interactive information manager should be configured ideally to complement 
the decision making process, leading the user through a series of steps to determine the 
optimal answer. This is not usually possible! In addition, the system should provide a 
consistent interface in keeping with the user’s conceptual model of how the information 
wUl be utilized. The user’s conceptual model is the knowledge base the user has 
developed to rationalize the behavior of a system. Violating the user’s model may lead 
to confusion, long learning times, and more critically, poor retention of the process as 
well as undermining his motivation to use the system. TDAs allow a more unstructured 
"what-if simulation and create a simulation of probable events resulting from each 
follow-on decision. For example, TDAs using a simulation model can show the effects 
of six hours of repair work within a few minutes. This provides the EMT with a 
’snapshot’ of an anticipated future situation, the desirability of which can then be 
evaluated. 

E. STORYBOARDING AS A TOOL FOR SOLVING PROBLEMS 

It has been recognized that a failure to determine adequately the requirements of an 
information system (IS) can often lead to the automation of the wrong things. Systems 
that are implemented with insufficient user input have led to systems that are not used. 
One study found that: 



23 



20-40% of all system problems can be traced to problems in system development • 
process, while 60-80% can be traced to inaccurate requirements definitions. The 
message is clear: know thy user. (Andriole, 1991, p. 82) 

Systems that meet either the user’s or task requirements may fail to meet the larger 

organization goals or mission and hence may not support the ultimate organization 

mission. The best requirements analysis would be to form a "matrix linking aU three 

dimensions (user, task, and organizational/doctrinal) together." (Andriole, 1987, p. 82). 

Requirements are often not incorporated into the eventual system. Several studies 
trying to understand why this occurs could reach no conclusive findings. However it can 
be said that: 

The systems design and developmental process cannot be successfully 
implemented unless requirements are identified and refined via some verifiable 
methodology. (Andriole, 1987, p. 83) 

After countless systems were thrown out due largely to their incompatibility with 
established efficient problem-solving procedures, designers began to take note of 
the environment in which their systems were expected to perform. (Andriole, 1987, 
p. 85) 



One proposed solution to overcome the translation of a conceptual system to an 
operational system has been the prototyping methodology. A prototype is the shell of the 
final proposed system, vahdated by the user. The prototype provides most of the 
graphical or input/output functions to ensure the system designer has adequately 
understood the requirements. The review of the prototype will also address whether the 
user adequately described, or conceptualized, the system during requirements analysis. 
By validating the requirements early in the design process, revision or correction of the 
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requirements may be accomplished with less costs and problems than by waiting for the 
finished product. 

A specific form of prototyping is stotyboarding. Storyboards are an interactive 
attempt to capture the screen and systems interactions during the design process. 
Storyboards are created by the designer and validated by the user. Each input/output 
screen or ’page’ is connected in a series of screens for the user to traverse. The user’s 
traversal of the screens simulates actions which would be done on the finished system 
without real data. The results of the ’story’ should be a set of screens that the designer 
will program to meet the user’s needs and expectations. 

The storyboard concept is not constrained to the design process. The EMT could 
record or trace his steps in solving a problem, or simulate a situation to determine the 
outcome of decisions. If the results are not as desired, the story may be ’retold’ running 
through different steps until a best or satisfactory ending is found for the scenario being 
considered. 

F. REVISED SCHEMA FOR TEDSS AS A TDA 

The present TEDSS may be simplistically considered an enhanced database package 
with preprogrammed queries. The spatial relationship of communication assets are stored 
within TEDSS, but the utilization of these relationships in solving problems is not 
transferred to the user. TEDSS requires textual input and provides textual or graphical 
(Mapinfo) output to questions regarding asset availability. The user must make a mental 
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model of the geographic area and transfer the text information entered into or received 
from TEDSS to his spatial model to solve problems. 

The more information you can absorb visually, the quicker you can come to a 
decision. Everyone can read a map. It doesn’t look abstract, and it’s much more 
appealing that looking at tables of figures. (Bylinsky, 1989) 

The proposed revised TEDSS, shown in Figure 3, proposes moving from a primarily 
text based input/output to a graphical one. Communication whenever possible will be 
done through pointing, or selecting from a number of options and entry from a keyboard. 
The user will determine which method is most suited to his needs. 




Figure 3 Proposed TEDSS II block diagram 
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The proposed system, called TEDSS II for clarity, will utilize a graphical user 
interface (GUI) windowing environment. The GUI is the ’glue’ for the system; it must 
support multiple windows to allow mental comparisons between different scenarios. 

TEDSS II will also utilize a graphical metaphor for the presentation of information 
on locations. A geographic information system (GIS) will be used as the primary method 
for displaying and inputting information related to a specific location. By pointing, the 
users will define the area of interest on a map, then navigate through menus and dialogue 
boxes to query data, with the results displayed on the map. By the use of a graphical 
user interface and a windowing system, the user may have information on the area in 
several different forms located in different windows. For example, the EMT may have 
the GIS showing a map of the affected area in one window, a separate window with the 
results of an structured query language (SQL) query listing all nodes in a particular 
network in the region, and a third window with a draft message listing the priority of 
service restoration as generated by XTRAM operating in fourth window. 

TEDSS n will attempt to minimize requirements for the user to switch between 
input devices by presenting a number of menu selections in a dialogue box. The user 
may select from a presented list or enter an alternate answer. Query results will normally 
be mapped onto an existing display map or can be presented in a separate window. The 
primary method of navigation will be the menus and dialogue boxes. However a direct 
SQL link to the database can be provided to allow the user to create a query manually 
when desired. The SQL query interface will allow knowledgeable users to quickly create 
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complex queries when the menu selections do not immediately support the information 
presentation required. 

TEDSS n use of windows and a ’point and shoot’ selection process of navigating 
through menus and dialogues boxes should facilitate the learning of TEDSS, provide tools 
for the EMT to configure and maximize use of the system, and remove the artificial 
barriers to effective decision making present in the current system. 
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rv. COMPONENTS OF PROPOSED SYSTEM 



TEDSS n as outlined in the previous chapter will be oriented heavily toward a 
graphical implementation allowing the user to select and handle information primarily in 
a graphical rather than textual form. Options for the user who needs or desires direct 
control of the data wiU also be available. The system should not define how things 
should be done, but rather support what the emergency management team (EMT) needs 
to accomplish his mission. 

TEDSS n will consist of three core sections: the graphical user interface (GUI), 
the geographic information system (GIS) and a database storage mechanism. The 
remaining components or modules in the proposed system and other applications to be 
developed wUl serve to enhance system capabilities. They may be added incrementally 
as the technology and users’ expectations advance. The user wiU interface with each 
component through the GUI. 

The model base wUl contain the damage assessment model and other tools for 
shaping the data to assist in decision making. Additional models to facilitate hurricane 
tracking or assessing earthquake damage may be added if useful to the National 
Communications System (NCS). AU models would access data from the database and use 
the GUI or GIS to present the results of the model. While additional models wUl be 
helpful in extending the power of TEDSS, the models may require modifications to insure 
conformance with the established common GUI. Failure to insure that the integrity and 
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conformance to the interface is maintained in all components will be detrimental to the 
TEDSS n usability. 

A voice recognition interface wUl provide an alternate method of menu navigation 
and may be useful in command center operations and briefings. The following sub- 
sections address these system components in greater detail. 



A. GRAPHICAL USER INTERFACE (GUI) 

The graphical interface or GUI can be considered the ’glue’ which holds the system 
together and makes aU the parts appear as an integral unit: "’a single system image’ 
concept where the complexities of the environment are hidden behind a user-oriented 
interface." (Nicholls, 1990, p. 164). The GUI concept is based on supplying a uniform 
way of presenting menu selections and information to the user. 

To achieve these goals, the GUI imposes a set of restrictions on the methods for 
program and user interaction, with a suggested set of standards based on experience 
and UI research. Not only is this usually better designed than the ad hoc UI of 
current applications, it is consistent across the application spectrum. Learning a 
new application under a GUI benefits from the transference of previous learning 
because of UI consistency. (Nicholls, 1990, p. 164) 

The GUI’s adherence to a set of standards in TEDSS II applications will greatly 

enhance training by requiring the user to learn new capabilities rather than new 

procedures. The ability to add new functional components or models to TEDSS II while 

using a common interface will allow the EMT to rapidly assimilate new capabilities or 

update existing systems with little or no additional training. 

Because such crises are so infrequent, the training mode [for emergency 
management] becomes even more essential than for business decisions. (Seagle, 
Duchessi and Belardo, 1985, p. 66) 
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Once the user is introduced to a GUI and understands its basic interface structure, 



the learning of TEDSS can be focused primarily on the problem of re-establishing 
communications. 

1. Advantages of a GUI 

The primary advantages of a GUI is that the user needs only master a single 
standard method of interfacing with applications. Each computer application is required 
to conform to a standard interface which insures that users work with the same interface 
regardless of the application. This simplifies the familiarization process and reduces 
training time. While standards are an important advantage to a GUI for emergency 
management, a GUI’s ability to provide graphical representations and communicate 
visually instead of textually may be more important to the EMT. 

The old adage of ’a picture is worth a thousand words’ is true for users. 
Computer users at all skill levels master computer tasks more rapidly when done in a 
graphical environment. The EMT, using a GUI in concert with a visued map model 
(GIS), where not only location information is presented consistently with thek mental 
model but colors and icons are used effectively, may be able to assimilate significantly 
more information than with the current TEDSS. A GUI’s ability to expand or contract 
views and present data in several forms and scales should allow TEDSS II to present 
information in a way that is more meaningful to the EMT. TEDSS II makes a conceptual 
shift from requking the user to understand the system in order to accomplish his job to 
making the system support the user and his needs. 
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2. GUI Flavors 



There are presently four commercially successful GUIs in wide use today; 
Microsoft (MS) Windows, Apple Macintosh (MAC), Presentation Manager (PM), and 
X-Windows. Each GUI is wedded to a specific operating system and in many respects 
cannot be considered separately from the operating system. However, developers have 
been trying to convert applications written for one GUI to other GUIs. For example, MS 
Windows applications may be used in OS/2, version 2.0, and UNIX workstations with 
additional specialized hardware may operate Macintosh software concurrently with X- 
Windows. 

All of the above GUIs use a windowing metaphor that allows users to resize, 
move, hide or overlap windows as desired. Additionally most support the ability to 
minimize a window into an icon to clean up the screen or ’desktop.’ AH GUIs, except 
MS Windows, require the user to utilize a mouse or pointing device. The ability to 
effectively integrate a pointing device is required for an efficient work environment. 
While each GUI performs the same basic function, users may disagree as to the ability 
and ’user friendliness’ of each implementation. TTie following sections provide a quick 
overview of the salient features of the four GUI environments. Chapter V addresses the 
operating system issues associated with GUIs. 

a. Microsoft Windows (WIN 3) 

MS Windows (WIN3), was released commercially in 1987. With the 
release of version 3.0 m 1990, it has become a dominant force in the commercial softv.-are 
market. WIN3 operates as a graphical shell to DOS, creating either a pre-emptive or 
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cooperative multi-tasking environment depending on the WINS mode utilized. WINS 
does not require a pointing device, but is significantly more difficult to use without one. 
The use of resizable windows and icons guides the user through most tasks. WINS 
supports the ability of users to cut text or graphics from one document window and paste 
it into another document. However some tasks such as managing applications and adding 
programs are not intuitively obvious. Microsoft adopted IBM’s Common User Access 
(CUA) standards to specify the basic menu structure of applications and what actions 
specific keys should perform. However, the standards are not always followed by 
application developers, especially in early WIN applications. 

While WIN3 greatly simplifies many computer tasks, it is not always a 
stable platform. WIN3 itself may abort for unknown reasons, called unrecoverable 
application errors (UAE), because of incompatibility of WEN3 and the hardware, or more 
often by a violation of a process running in one of the windows. 

Because DOS does not support multi-tasking, it cannot provide WIN3 
with support should two applications try and use the same resources. Therefore, WIN3 
must create the multi-tasking environment while operating as a single application in DOS. 
WIN3’s multi-tasking environment is very powerful, but is susceptible to unexpected 
terminations when an application operating in WTN3 fails or acts improperly on system 
resources. The result of these types of problems may require the computer to be restarted 
resulting in a loss of all unsaved work. Microsoft has stated it intends to eventually 
replace/remove DOS and allow WIN3 to take over the operating system responsibilities 
in future versions which should significantly improve WIN3’s stability. Initially 
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Microsoft planned to merge the OS/2 operating system and Windows GUI platforms, 
however they have recently modified their development plans concerning WINS, so this 
direction may change again. (Sherer, 1991, p. 1) 

b. Apple Macintosh (MAC) 

The Apple Macintosh (MAC), released initially in 1984, may be the 
oldest commercial GUI. It was derived from research by Xerox Corporation and all GUI 
tend to be judged as to how well they "look like a MAC." The MAC interface is refined, 
intuitive and consistent across all applications. The MAC’S GUI is intimately and 
inseparably tied to the operating system. Unlike DOS, the MAC provides standard 
methods for controlling all input and output operations. The MAC supports cutting and 
pasting between documents, and dynamically linking programs. For example, a chart may 
be linked to a spreadsheet so that when numbers in the spreadsheet are changed the graph 
is adjusted. 

c. Presentation Manager (PM) 

Presentation Manager (PM) released initially in 1988, was developed for 
International Business Machines (IBM) Operating System/2 (OS/2), which was released 
in 1987 by Microsoft Coiporation. WhUe PM was not critical to the original function of 
OS/2, it is now the primary interface for the operating system and will be considered 
synonymous with PM for the remainder of the thesis. PM does not use as many graphical 
metaphors as WINS or MAC, but does support the same basic features for configuring 
the desktop and for inter-application data transfer. 
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OS/2, like the Macintosh, has an advantage in that it is a new operating 
system, and is not constrained to support applications developed for previous systems, as 
was the case for MS Windows and DOS. OS/2 uses the CUA to specify in detail how 
applications should create their menu structure and keystroke definitions. Additionally 
because OS/2 and PM were designed from the start as a multi-tasking, multi-threaded 
operating system, OS/2 has a robust ability to handle application failures without 
impacting other applications. This provides a more stable and reliable environment than 
WINS, by not allowing one process to disable the whole system. 

d. X-Windows 

X-Windows, strictly speaking is not a GUI for UNIX, but a "network 
transparent windowing system." (Fielder, 1989, p. 124). It provides a common base for 
UNIX user and application programs. Developed by Massachusetts Institute of 
Technology (MIT) in cooperation with industry representatives, X-Windows is a hardware 
independent method of displaying graphical information. It allows software developers 
to develop programs that concentrate more on the functions of an application rather than 
the mechanics of displaying it. Utilizing X-Windows as a standard baseline. Open Look 
(a GUI promoted by Sun, AT&T, and UNIX International [UI]) and Motif (promoted by 
the Open Software Foundation [OSF]) are competing in the marketplace to define a 
’standard’ GUI for UNIX/workstation software market. Because X-Windows based GUIs 
did not define the exact details of application menus prior to some applications being 
released, the user interface and menu structure are not entirely consistent across 
applications. X-Windows is designed to operate transparently on a network, but will 
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operate on stand alone machine as well. As with the preceding GUIs, X-Windows; 
through UNIX inter-process communications, supports data linking between applications. 

3. Considerations in GUI Selection 

The GUI wiU affect TEDSS II more than any other single component in the 
system. Its selection should be based on what system wiU best satisfy the present and 
future requirements of TEDSS. Issues such as development tools and applications are 
important, but "as always, the requirements definition should determine the relationship 
between structure and fiexibility\ designer preference should never determine it." 
(Andriole, 1989, p. 105). 

Each of the four GUIs discussed has certain advantages that the others do not, 
however each environment has potential flaws that could seriously impede TEDSS II 
usability, stability and growth potential. Because of the intimate relation between the 
GUI and the operating system, a summary of their strengths and weakness will be 
included after discussing operating system issues. 

B. GEOGRAPHIC INFORMATION SYSTEM (GIS) 

A GIS is a spatial database which manipulates location information in the same 
ways as a conventional database handles data. GISs allows information retrieval on 
spatial data where the geographic location is the ’common key’ for the data. 

A ’true’ GIS does not store maps in the conventional sense; rather they store a 
mapping of locations on the earth’s surface as well as any relationships between locations. 
For example, a state is stored as a collection of points defined by latitudes and longitudes. 
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with a defined relationship, normally a line or arc, that relates the points which outline 
the border of the state. Rivers and other landmarks are stored similarly. When the GIS 
displays the stored information the data is projected onto the screen and by use of color 
codes and icons a ’map’ is drawn. The map is a graphical model that is expedient for 
human interpretation of data, but a GIS interprets it as a collection of data points with 
attributes. 

Most GIS store information in overlays, like sheets of tracing paper over a map, 
each overlay containing one specific type of attribute and associated with specific point(s). 
For TEDSS each overlay could be a telecommunications network of concern to the EMT. 
When the EMT is evaluating options with the GIS, only the overlays of concern need be 
projected onto the area map, providing an intelligent filtering of information to the user. 

GISs have traditionally been used by relatively few people due to their taxing 
hardware performance requirements, however powerful workstations now make these 
systems available to an increasingly large numbers of users. Police departments use GISs 
to identify crime trends, marketing people use demographic information to target specific 
zip codes and names, and city governments use GIS to track electrical, water and 
sanitary systems, and to review digging permits. 

1. Flavors: Full vs. Limited GIS 

The breadth of capabilities in GISs vary dramatically. More elaborate GIS 
may provide procedures for complex statistical profiles of demographic, economic, or 
other criteria projected onto a map to assist in marketing decisions and political 
redistricting. A more elementary GIS may simply display a map with major roads and 
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cities and other user defined attributes. TEDSS need for GIS capabilities will depend to 
a large extent on the present and future availability of data of a spatial nature for the GIS. 

An example of a more powerful GIS is Comgraphix’s MapGraphix program 
which is representative of GISs supponed on many platforms. Comgraphix’s MapGraphix 
program for the Macintosh is representative of a fiill GIS which provides a robust set of 
tools to support users needs for GIS support in one package. MapGraphix is able to 
handle maps maintained in fifteen different coordinate systems, allows users to create and 
customize icons for placement on maps, supports file and map overlay locking for 
security control, operates across a local area network, and imports/exports maps and data 
to a multitude of platforms and other application programs. The program can manage or 
access data through a database co-located on the machine or a database server using an 
SQL interface. Mapgraphix offers development kits to allow users to generate customized 
applications and to extend current abilities to specialized mapping functions. 

TerraView by TerraLogics Inc, is an example of a more limited system which 
takes a slightly different approach to GIS support. TerraView operates on X-Windows, 
Digital and IBM mini-computers, and IBM PC’s and effectively provide a toolkit for 
application developers to create a GIS product. TerraView has a library of functions to 
facilitate mapping applications through C programming language function calls. 
Applications that are developed by using function calls may be easily ported to different 
platforms, and remain independent of the hardware. TerraView allows users to provide 
as many or as few options in a mapping program, and provides an optimized spatial 
search and retrieval engine accessing an external database to provide increased system 
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speed. The ability to create tailored applications to provide optimized performance allows 
TerraView applications to run potentially quicker than a comparable full featured GIS. 

TEDSS presently stores location data about network nodes and other 
communication assets. If little additional data is to be collected or monitored by TEDSS, 
and if access to communication asset information is not provided by commercial carriers, 
many commercially aveiilable GIS will be more powerful than what TEDSS II needs. The 
use of a GIS which has more capabilities than required will offer TEDSS growth 
capability, but it will also provide sub-optimal performance at the present time. An 
option to limit the performance penalty from using an overpowered GIS in TEDSS is to 
program a custom GIS for TEDSS such as TerraView supports that implements only those 
features required at the present time, but which allows upgrading as needs evolve. 

2. Utilization of a GIS in TEDSS 

The GIS offers many capabilities to the EMT. Table 1 lists several questions 
that the EMT might pose and possible information the GIS could provide the user or 
model. 
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TABLE 1: EMT questions that a GIS could assist in answering 



Emergency Management Team 
Questions 


Information the GIS could 
assimilate 


Describe the affected location in 
different ways, and what is the impact 
of the damage? 


The following resources are in the area 
... These networks are down and the 
sites in blue have no alternate 
communication paths. 


Hunting through geographic space to 
find where certain conditions are 
satisfied. 


How many nodes are potentially 
affected by the earthquake in this 
region, within a 30 mile radius? 


What is the differences between the 
results across two moments in time? 


How many nodes have been repaired 
in the last hour? 


What anomalies are there that do not fit 
the normal pattern and where are they 
located? 


How many nodes were not affected in 
the damaged area that the model 
predicted would be? 


Other questions that the GIS could 
answer. 


If Node A is restored, how many other 
nodes wiU be reconnected? | 



The primary interface for the user and GIS will be pointing devices to 
dynamically define and adjust the geographic area of interest. For example, during an 
earthquake recovery effort, the EMT could identify the affected area by selecting an 
appropriate map area, save it as a default and then proceed to analyze the situation as 
information becomes available. If requested to supply some form of satellite feed to a 
site, the EMT could query the DBMS through the GIS to "show all satellite ground 
stations within three miles," or "list all sites that utilize the damaged satellite dish." 

3. Considerations in GIS Selection 

The efficient use of a GIS rests critically on the proper structuring of the 
underlying database. Consideration must be given to how the data is input, accessed. 



40 



modified, maintained, and its frequency of use. Security issues such as separate layers 
for the communications assets of ATT, MCI and other vendors must be addressed. WUl 
security requirements dictate, or be subjugated to, performance requirements? "It is 
difficult to overstress the importance of adequately documenting the database design and 
subsequent implementation efforts." (Chambers, 1989) 

Additionally GIS features should be evaluated with respect to TEDSS II 
requirements, as commercial GIS’s may possess more features than can be utilized by 
TEDSS II. Many GISs, such as MapGraphtx, support data presentation methods which 
TEDSS currently does not support. If this is the case, perhaps system performance can 
be improved by developing a custom GIS with only the requisite features included, or 
implemented by a developer with products such as TerraView. 

C. DATA 

The current TEDSS database consists of approximately thirty megabytes of 
communications system information. However, TEDSS does not present the information 
in a very usable fashion and poor performance is a problem. TEDSS has consistently 
provided slow response to even the simple preprogrammed queries. Short and Bockenek 
(1989, p. 105) identified several areas in TEDSS where simple changes to the INGRES 
database access and structure procedures resulted in 40-90% improvement of processing 
speed. During my use of TEDSS, a query to identify all nodes in the state of Virginia 
took in excess of 15 minutes to execute. Users expect better response times, especially 
from a system to support emergency management. 
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The current TEDSS database appears to be poorly designed. Because TEDSS does 
not allow freeform queries, those queries which are supported should have been optimized 
for quick response. Short and Bockenek (1989) identified several deficiencies in their 
limited review of the TEDSS DBMS that imply the DBMS designers were not proficient 
in coding. While the continued lack of a data dictionary or documented database schema 
for TEDSS indicates that overall database maintenance has not been a priority. 

TEDSS n wiU require the use of a database to support other components of the 
system. Several data requirements and analysis steps are necessary to implement the 
database and to address the current deficiencies in data management. Presently the 
National NCS Office is responsible for incorporating changes to the TEDSS database and 
distributing updates. However no fiiU time Database Administrator (DBA) to monitor 
both the quality and accuracy of the data is presently assigned. Although NCS is 
currently in the process of hiring a DBA, a structured method of validation and 
maintenance of the TEDSS database should be addressed. The worst time to identify 
errors or omissions in the database would be during a crisis. 

Three options to provide the required database management system (DBMS) 
capabilities in TEDSS will be considered. 

1. Maintain the lease of the existing INGRES database system, and have TEDSS continue 
to utilLze the present database. 

2. Develop a custom DBMS using C or other programming language, and convert the 
existing database to the new DBMS. 

3. Purchase, rather than lease, a DBMS developed for the targeted hardware platfomi and 
convert the existing database to the new DBMS. 
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The first option to utilize the existing INGRES database in TEDSS II offers the 
cheapest option for initial acquisition, but will not be the most cost effective solution on 
a long term basis. INGRES was initially developed for use on mini and mainframe 
computers; in the process of downsizing the system to operate on a PC, significant 
performance problems occur. The extensive overhead inherent in a large DBMS such as 
INGRES extracts a performance penalty on TEDSS and offers many capabilities that will 
not be utilized in TEDSS. 

The policy of leasing UNIX applications on an annual basis instead of purchasing 
a limited lifetime license for the program and paying for all subsequent program updates 
developed is not cost effective. The INGRES program offers litde if any functional 
improvements from many commercial products that may be purchased without having to 
pay onerous annual lease costs. A life cycle saving of many thousands of dollars wiU 
result from purchasing rather leasing the DBMS. 

The second option to develop a custom DBMS to support TEDSS will offer the best 
performance but will be the most expensive in terms of development and life cycle 
maintenance costs. TEDSS currently is not expected to possess any unique data 
requirements that are not met by dozens of commercial available DBMSs. A custom 
DBMS requires a significant amount of time and money to develop in return for a 
relatively small gain in speed. A significantly larger gain in speed per dollar of 
investment would be obtained by fully normalizing the data relationships in TEDSS and 
optimizing data storage mechanisms to improve retrieval speed. 
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The third method of purchasing rather than leasing a DBMS offers both the most 
cost effective option and maximum flexibility for TEDSS. While the DBMS selected to 
replace INGRES must operate on the target operating system, in many cases, it may be 
picked independently of the operating system as most major DBMS offer peer compatible 
versions. Oracle, Ashton Tate, Fox and others offer DBMSs that can operate in UNIX, 
DOS and Macintosh operating systems. 

The present INGRES database offers a rich assortment of capabilities appropriate 
for a mini-computer. Support for multiple users, concmrency control, data locking, and 
other data sharing features which are not currently utilized by TEDSS may be a 
significant cause of the performance problems associated with TEDSS. Consideration 
should be given to using databases which have been developed for single user, single- 
tasking PCs. While they lack some of the more elaborate data integrity abilities 
characteristic of multiple user DBMS, they provide a more optimized performance for the 
PC environment such as FoxPro, and Paradox. Unless the type or amount of data, or the 
number of concurrent users increases significantly TEDSS will not be able to utilize the 
majority of INGRES or other mini-computer database features, and will continue to suffer 
a performance penalty from this unused overhead. 

Whatever database is selected should support the ANSI Structured Query Language 
(SQL) interface. This standard query method will offer a consistent external interface to 
the user, and not unnecessarily tie TEDSS to a specific DBMS. 
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D. MODELS 



The model section of TEDSS currently contains only the Damage Assessment 
model. As additional models are developed and validated they would be incorporated into 
TEDSS n. The XTRAM model should be examined to determine if the knowledge rules 
developed are valid. If so, the rules and information from XTRAM should be transferred 
to TEDSS. The Department of Defense, Federal Emergency Management Agencies and 
other Federal Agencies should be investigated for models that could assist in emergency 
management. If practical models are found, they should be adapted for use in TEDSS, 
rather than developing them independently. 

All models regardless of source should be modified to adjust to the GUI interface 
standards and ensure that all data is accessed from the DBMS and not hidden within the 
model. When model interaction involves spatial information, the information by default 
should be interfaced through the GIS. 

E. OTHER COMPONENTS 

Voice recognition offers the capabilities today to enhance EMT performance with 
TEDSS. People communicate verbally at two-hundred words per minute yet few people 
type better than sixty words per minute. Studies have shown that people work more 
effectively when using more of their sensory skills. Presently TEDSS utilizes the users’ 
tactile (hands) and limited visual senses to input or process information. TEDSS II will 
emphasize the visual by increasing graphics, and simplify the remaining tactile 
requirements by using voice recognition. Voice recognition allows the user to tell the 
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machine the desired action without having to translate commands into keystrokes. As 
members of the EMT will not normally be skilled typists, the ability to instruct the 
machine verbally should allow quicker control and less entry errors, and permit the EMT 
to be doing other tasks concurrently with TEDSS operations. (Lee, Hauptmann and 
Rudnicky, 1990, p. 225). 

Voice recognition is not the same as a natural language interface. The computer 
responds to recognized verbal commands in a pre-programmed manner rather than 
translating sentence intention. The computer does understand the phonetic difference 
between the words "up" and "down," however it translates only in the sense that the word 
"up" signifies a specific keystroke and "down" a different keystroke. For example, a 
product called the Voice Navigator II for the Apple Macintosh computer can be trained 
to recognize several thousand different commands for each user. The Voice Navigator 
will allow the user to open a file, edit, move or delete text and graphics, then save the 
file without touching the keyboard. The system may be trained to simulate any command 
or keystroke. TEDSS could use this ability to allow the EMT to open a window, display 
a map of the region, zoom in to a specific state, and simulate the effect of a bomb blast 
and identify all networks that will be affected in a thirty mile radius without ever 
touching the keyboard. 

F. SUMMARY 

This chapter has addressed the major components of the proposed system. TEDSS 
II should be considered an evolving system able to support future missions by utUizing 
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emerging technology to enhance the decision making process. By the effective use of a 
GUI and GIS, users should be able to generate interactively queries and information 
presentations that allow them to ’see’ what is transpiring instead of having to derive this 
information from reviewing voluminous data retrievals and printouts. The user will 
decide the level of detail to view in data presentation. TEDSS II ’s use of a GUI allows 
the user to define a window to view desired information and select the presentation 
format as text from the database, or to have it translated into a graphic image by the GIS. 
Further TEDSS II should ideally allow the EMT to complete a major portion of their 
work through voice interaction instead of requiring the use of the keyboard. 

TEDSS II should be developed and managed to meet these goals and not be 
restrained from adopting new software or hardware when appropriate. The following 
chapter will address software management issues that affect future development. 
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V. FUTURE SOFTWARE CONSIDERATIONS 



This chapter reviews several project management issues in the TEDSS II program 
relating to Life Cycle Management (LCM) and development costs. The focus is on 
critical management issues that should be decided or evaluated prior to initiating 
development of subsequent TEDSS implementations. 

A. LIFE CYCLE MANAGEMENT 

TEDSS has stmggled to fulfUl a changing role in emergency communications 
management. The system was developed initially to manage the large amount of 
communications assets in the early 1980s. As with similar computer systems of the 
period, the computer was considered more of an electronic filing cabinet than a tool to 
support decision making. As the TEDSS program evolved to meet the EMT’s 
requirements and the changing needs of the organization, the improvements have been 
disjointed and do not appear to foUow a coordinated development plan or overall goal 
beyond elimination of immediate problems. 

TEDSS II needs to undergo a complete requirements evaluation and determination 
of system goals prior to developing a follow-on system. The existing TEDSS serves a 
valuable role as a prototype that has educated both users and management to the 
capabilities and limitations of computer assisted emergency management. But if TEDSS 
II is to fulfill both current requirements and serve as a platform for future growth, the 
organization’s long term goals for TEDSS must be established. 
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B. LONG-TERM SYSTEM GROWTH/GOALS 



Computers currently impact almost every segment of our lives, and society is 
becoming increasingly more dependent on them to support and improve the quality of life. 
Advances in artificial intelligence (AI) and DSSs continue to produce virtual machines 
that can handle increasingly complex tasks dependably and reliably. As the number of 
computers have increased, the amount of data created, modified and transmitted 
electronically has exploded. Computer networks spanning the nation are utilized daily 
and must be maintained at all times to keep the data flowing reliably. TEDSS’ goal to 
support the maintenance of certain networks wiU continue to increase in importance in 
the future. While overt military and terrorist actions become less likely, natural disasters 
will always present possibilities for rapid destruction of communication assets. Therefore, 
in planning TEDSS future, the overall NCS mission should be evaluated to determine 
what critical tasks and missions must be maintained, the information they require, and the 
sources of the information to establish a set of long term goals for TEDSS. 

The TEDSS platform can offer the EMT many tools to provide effective decision 
management, if and only if, TEDSS has correct and accurate mformation. While not 
privy to the exact data types, formats and structures provided by communication vendors 
such as ATT and MCI, the style, content, quality and future access to the information will 
affect TEDSS long term goals. If TEDSS is unable to obtain current information about 
communication assets from commercial vendors, the goals and use of TEDSS will be 
subverted. 
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C. USEABILITY AND ADAPTABILITY 



TEDSS n must be useable and adaptable to each individual EMT member to allow 
the maximum effective use of TEDSS II. The GUI will allow the user to adapt and 
customize displays in many forms, to maintain multiple windows, to set default 
parameters, to vary fonts, and to screen color selections. However, the users’ ability to 
customize is a mixed benefit to TEDSS II. A structured interface provides a standard 
environment to which everyone may become acclimated, but it may also artificially 
restrict the user’s method of problem solving much like TEDSS present menu interface 
does. On the other hand, the user’s ability to endlessly customize screens may also 
complicate the expected emergency management scenarios in which multiple users operate 
the system continuously until the emergency situation is resolved. This dilemma is 
similar to a shared desk in an office. When a worker is restricted in the location and 
arrangement of items on the desktop it may be easier for others to find things on his desk, 
but at the cost of constraining his use of the desk (menus). However, if no rules are 
applied to desktop arrangement when that worker is relieved (e.g. when the EMT changes 
shift), the substitute will require time to acclimate to the existing desktop condition until 
it is modified to an arrangement that is efficient for him. Thus there is a tradeoff 
between flexibility and efficiency. 

This conflict between the need to customize the interface and maintain standards 
can be solved by allowing the user to define his workspace. TEDSS users should be able 
to dynamically define and adjust window size, color, and location and then save these 
screen profiles for later retrieval. Users would then be able to define, save and recall a 
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work environment without imposing that environment on other users. TEDSS could also 
define several environment templates which would serve as reference points for a new 
user until he can determine the screen design(s) that best supports his work. For example 
a default setup for the tracking of hurricanes could be established and maintained in 
TEDSS. Novice users could use the predefined screen initially and, as they become more 
sophisticated, modify it to accommodate personal preferences. 

The ability to configure the screen and other system components should be 
addressed early in development. Each TEDSS user should probably develop a personal 
dataset composed of screen configurations, default options, screen colors and voice 
recognition files that comprise the unique elements of his work environment. If the 
dataset is maintained by the user in a manner similar to an identification card, he may 
then go to any TEDSS II system, insert the dataset of preferences, and immediately 
recreate his preferred work environment. 

D. SYSTEM ADMINISTRATION AND MAINTENANCE 

TEDSS n win require a shift in program administration which should offer a good 
starting point to modify the software development methods to reduce overall system costs. 

TEDSS presently has a program and project manager, but does not appear to have 
any one person responsible for the daily administrative work and maintenance of the 
system. Additionally the National office is responsible for database maintenance and 
updates back to the regional component, however no full or part time database 
administrator is utilized. Emergency management should not be assigned as a part time 
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task, without some alternative method of assessing the system’s ability to handle the 
emergency, as it will only be during the times of crisis that omitted actions will be 
identified. The simulations and training conducted by NCS serve to validate the TEDSS 
database, only if the accuracy of data is truly verified, and those steps that depend on the 
accuracy of the information are not artificially executed. 

As outlined in the previous sections, NCS must establish the goals for TEDSS, 
develop a prototype of TEDSS n, and iteratively refine TEDSS II towards the system 
goals. TEDSS, like the emergency management situations it is designed to support, wiU 
always be in a state of change. As TEDSS improves, the EMT’s expectations will grow 
accordingly. The initial version of TEDSS, while coming to the end of its useful life, has 
successfully introduced the EMT to a computerized decision aid. The NCS should 
harness the knowledge of its users in the development of TEDSS II initial requirements, 
and determine what areas to stress in the upgrades after the initial fielding. The NCS 
simulations and training exercises offer a splendid opportunity to solicit real-time 
feedback on system requirements and deficiencies. Since the final capabilities of TEDSS 
will depend on the data it can access, it may be prudent to involve the commercial 
vendors which will ultimately supply the data. 

Sections of TEDSS has been implemented in various programming languages 
including C, Fortran, and assembler while using an undetermined software methodology. 
If TEDSS II is viewed as an opportunity to start over using the ideas developed in the 
initial prototype, several softwaie development methodologies should be considered. 
These would provide a solid base for the evolutionary enhancement of TEDSS. Computer 
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aided software engineering (CASE) tools and object-oriented design and programming 
may offer methods to decrease development cost while providing more implementation 
flexibility over the TEDSS II system life. 

CASE tools automate and structure the translation of system requirements into 
software. They assist in establishing and maintaining the database and an associated data 
dictionary, and when used with code generators, can automate the generation of software 
to support the interconnection of different components in TEDSS. 

Object Oriented Analysis and Programming (OOA/OOP) has been touted as a 
solution to the software maintenance problem. OOA/OOP is a paradigm shift in software 
development from what a process does to what the functional parts of the program are. 
Although it remains to be seen whether OOP/OOA will solve the significant cost and 
manpower problems associated with software maintenance, it does offer a way to reduce 
costs. 

The change in focus from processes to objects makes the initial development of an 
object-oriented design more difficult and expensive. However, once designed, the objects 
can be reused in future software development efforts resulting in lower development costs 
in follow on use. OOA/OOP defines everything as objects and requires all objects to 
communicate by messages with other objects. Preventing objects from accessing other 
objects’ code directly allows the internal workings of an object to be modified without 
affecting the larger system’s operation. This ability to change or enhance the internal 
functions of objects without affecting their external behavior results in a major reduc tion 
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in system maintenance costs. Many GUIs are provide an object-oriented environment’ 
however they may not have bee implements using object-oriented methodologies. 

Although OOA/OOP may be effective in the reduction of software life cycle costs, 
it may not bring cost savings initally to TEDSS. The lowered life cycle costs normally 
come from the reuse of previously defined objects in later projects. Since TEDSS will 
probably be a stand alone project, the ability to reuse modules may not arise. However, 
OOP may decrease the total maintenance effort over TEDSS II life. If additional models 
are developed for TEDSS they may be able to utilize OOA/OOP concepts by reusing 
objects from previous models. This is especially true with respect to displaying the 
effects of a model on the GIS maps. 

E. OPERATING SYSTEMS 

1. Multi-tasking and Multi-threading Requirements of Operating Systems 
The GUI places a significant load on the operating system. It allows several 
applications to be operating simultaneously and must manage the possibility of one 
program modifying data another program is utilizing concurrently. These non-trivial 
requirements can be satisfied by use of hardware and software configured in several ways 
of increasing complexity: 

1. Context switching 

2. Multi-tasking 

a. Pre-emptive multi-tasking 

b. Time-sliced multi-taskmg 
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c. Cooperative multi-tasking 
3. Multi-tasking with multi-threading 

The following will attempt to illustrate the subtle but significant difference between 
operating system capabilities. 

Context switching occurs when several programs are loaded into memory and 
the user alternates between applications. However, only one application is operating in 
the central processing unit (CPU) at a time, with the user determining which process is 
active. 

Multi-tasking occurs when several programs are loaded into memory 
simultaneously and are rapidly switched into and out of the CPU so that it appears to the 
users that all tasks are running towards completion. Multi-tasking comes in a range of 
flavors of decreasing robustness: pre-emptive, time-sliced and cooperative. 

Pre-emptive multi-tasking occurs when one process may ’preempt’ or bump 
another process because it has a higher priority. In time-sliced each process will get an 
equal share of the time with the CPU regardless if they can use it or not. In cooperative 
multi-tasking however, each process gets the CPU for an equal amount of time, but uses 
the CPU only as long as it needs it. Each process ’cooperates’ by giving the CPU up 
when it is waiting for other functions maximizing CPU use. Multi-tasking operating 
systems come in many subtle flavors from these broad categories listed, but the basic 
concepts of operation are similar. 
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Multi-threading is the ability of a process to be executed several times 
concurrently, using the same code segments in memory with a multi-tasking operating 
system. The primary advantage of multi-threading is the economical utilization of 
memory space. Multiple users or processes can use the same segment of memory without 
loading multiple copies of the program. A common example of multi-threading is word 
processing software on a mini or mainframe computer, several users can be editing 
documents simultaneously in the word processor. The operating system has only one 
copy of the program running and tracks what section of the software each user is in. 
TEDSS could use multi-threading when several views of a situation were required 
simultaneously using a GIS. Each view could be maintained concurrently as data changed 
and updated allowing multiple models to be forecasting concurrendy, with a decreased 
drain on system resources. 

It is interesting to note that TEDSS currently operates in a context switching 
mode since only TEDSS or Mapinfo may be used, however it is operating on a multi- 
tasking operating system, UNIX. This indicates that TEDSS is not currendy using the 
full capabilities of UNIX. This underscores the need for an investigation of the true 
requirements of TEDSS. 

2. GUIs and Operating Systems 

The current TEDSS utilization of two operating system environments 
unnecessarily complicates the programming and system maintenance environment. 
TEDSS n should detennine the best operating system for its needs and utilize only that 
operating system. As stated earlier, the operating system and the GUI are intimately 
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entwined, and one can not really be separated from the other. Some operating systems 
actually are inseparable from the GUI as in the case of the Apple Macintosh, while others 
are simply a shell, albeit a complicated one, such as Microsoft Windows (WINS) and X- 
Windows, they insulate the user from the operating system complexities and 
idiosyncracies. 

While the Macintosh has been a commercial product for almost ten years, 
most GUIs have only become commercially available with software applications in the 
last four or five years. Currently several platforms have begtm offering applications 
which will allow a GUI designed for one platform to operate as a process on another 
platform. For example. Sun Microsystems offers a MOTIF Shell that will allow a UNIX 
workstation to run MS Windows applications. However, not all combinations are 
available. Attempting to synthesize GUIs and operating systems to attain the best of all 
worlds may eventually lead to a loss of standards and undesirable complications. The 
following will discuss the major operating systems and the graphical shells they support. 

3. Personal Computer Disk Operating System (PC-DOS) 

PC-DOS and Microsoft Windows Version 3.0 (WINS) may be the largest (in 
volume) commercial software products in the marketplace**. DOS was developed for the 
IBM Personal Computer in 1981 as a single-user, single-tasking operating system for 
stand alone Personal Computer (PC). The current commercial version 5.0 offers many 



“The product Personal Computer Disk Operating System (PC-DOS), or Microsoft Disk 
Operating System (MS-DOS), or DOS will be used synonymously, as the difference in 
names is due to marketing and trademarks, and not a difference in technical capabilities. 
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evolutionary enhancements, but the operating system in general has some significant 
problems. DOS imposes restrictions on program segment size which prevents programs 
from effectively or efficiently using all memory present. This frequently necessitates 
programming ’tricks’ to accomplish the desired functions. Problems such as non-linear 
memory models, no memory partitions, are technical in nature but the effects are 
noticeable to the users in the form of performance penalties. 

Whereas DOS is a single task operating system, several commercial software 
products are sold to permit DOS to perform as multi-tasking operating system. WINS and 
Quarterdeck’s DESQview (DV) are examples of products which simulate a simple multi- 
tasking environment allowing multiple applications to operate concurrently. However, all 
of these products are not as robust as a true multi-tasking operating system. If a process 
fails in DV or WINS, it may cause all other processes to terminate. Because WINS and 
DV do not have complete control of the environment, they must ultimately depend on 
DOS for some functions. 

4. Apple Macintosh 

The MAC allows several applications to be loaded into memory 
simultaneously but currently offers only cooperative multi-tasking. The current version, 
Apple System 7.0, has improved networking abilities, and supports the dynamic linking 
of processes through Apple events. 

MAC’S use of cooperative multi-tasking means overall system performance 
will be no better than the worst-written program. The MAC, like WIN3, depends on a 
program to give up its processor time when waiting for an event such as a key pre.5s to 
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complete. If the program does not relinquish its time, the central processor unit (CPU) 
will sit idle. Therefore, if programs are written efficiently to use only the CPU time 
required, every process will run as fast as possible. 

5. IBM Operating System/2 (OS/2) 

OS/2 is a fully functional multi-tasking, multi -threaded operating system. 
Developed jointly by IBM and Microsoft, OS/2 was intended to replace DOS, and serve 
as the primary operating system on 80286 and higher Intel microprocessors. Initially an 
operating system, it is now similar to the MAC in that there is a blurry bounds between 
the operating system and the GUI. While OS/2 has not enjoyed widespread market 
success and suffers from a limited selection of applications, it has made significant 
inroads into specific segments of computer users. OS/2 is used as the operating system 
of choice in local area network (LAN) servers due to its high speed file system (HPFS) 
and programmed support of networks. The HPFS offers between 30 and 400 percent 
improvement in file access times compared to DOS using the same hardware. (Heller, 
1990, p. 168). 

Version 2.0 of OS/2 is currently in advanced beta testing and is expected to 
be released by the end of 1991. It has been promoted by IBM as "a better DOS than 
DOS and a better Windows than Windows." (Davis, 1991, p. 106). It is anticipated that 
version 2.0 will be able to multi-task OS/2 specific programs with MS Windows 3.0 and 
DOS programs. 

OS/2’s ability to support pre-emptive multi-tasking and multi-threaded 
processes, as well as to maintain a ’flat’ 32-bit memory model addresses many of DOS’s 
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shortcomings, with only a small decrease in single task performance. All multi-tasking 
operating systems carry a fixed amount of overhead that single task operating system do 
not. Therefore when running a single process, DOS may stiU be quicker than OS/2, 
however OS/2’s wider data bus and quicker file access methods may eventually make it 
a "better DOS than DOS." 

The latest release of OS/2, version 1.3, can operate DOS applications with few 
limitations. Furthermore, should an application terminate unexpectedly, it will not affect 
any other application because OS/2 has segmented memory to prevent one process from 
destroying another in memory. This feature makes OS/2 desirable for certain kinds of 
applications: "’mission-critical’ applications always crop up in discussions of OS/2. It’s 
rock solid." (UdeU, 1991, p. 98). 

OS/2’s lack of software applications base has not prevented it from often 
serving as a platform for developing DOS applications. Several CASE and programming 
tools for DOS and mainframe environments are available for OS/2 because it can simulate 
multiple DOS sessions and provide graceful degradation when an application aborts. 
Additionally, OS/2 similarities to UNIX offers a migration path for developers attempting 
to port applications from Workstations to DOS. OS/2 serves as an intermediary platform 
in this process. (Nicholls, 1990, p. 164) 

6. UNIX 

UNIX is a venerable operating system that has been in use for over twenty 
years. It operates on almost every hardware platform commercially available. U14IX 
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provides solid performance in a time-sliced pre-emptive multi-tasking, multi-user, multi- 
threading operating system. 

The UNIX operating system developed at Bell Laboratories was never 
intended to be a commercial product, but rather an internal laboratory computer operating 
system. The system became a commercial product more by default than design, and 
comes in many subtle flavors, such as ATT UNIX and Santa Cruz Operations UNIX. 
These flavors are not equivalent; while the basic concepts are the same, commands and 
other differences affect compatibility. While UNIX is powerful at the operating system 
level, it is not user friendly because of cryptic and non-intuitive commands. 

7. Comparison of Operating Systems 

The relative value of the operating system is directly related to the tasks it 
will be performing. TEDSS’ dependence on graphical presentations with multiple data 
views indicates that some form of multi-tasking is required. The emergency nature of its 
task implies that the system must be stable and not prone to failure. These following 
requirements would indicate that OS/2 or UNIX would be the preferable platforms. The 
Mac could also be a viable platform if the increased multi-tasking capabilities supported 
in System 7.0 are utilized in applications used in TEDSS. MS Windows 3.0 (WINS), 
while commercially successful, is susceptible to unusual and unexpected failures related 
to both hardware incompatibilities and interaction with DOS. 

If the GUI’s requirements for ease of use, availability of applications, and 
development tools were the primar>' considerations, a subjective evaluation would place 
the Macintosh first, followed by WIN3, UNIX, and OS/2. Macintosh’s well -developed 
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and tested GUI is extremely consistent across its broad range of applications which are 
normally more powerful than the current WINS applications. 

F. TEDSS SECURITY REQUIREMENTS 

A major issue for TEDSS is system security. No clear cut delineation of overall 
security requirements was found in TEDSS documentation. 

Individually, records in the EPMIS [TEDSS] data base are not considered to be 
classified; however, the entire collection of data is treated as SECRET. Industry 
data in the data base is considered as proprietary. (Booz, Allen and Hamilton 
Deployment Plan, 1988, p. 22) 

Further TEDSS "computer system is [utilizes] TEMPEST equipment." However some 
hardware that TEDSS operates on does not appear to be TEMPEST certified, specifically 
the color VGA monitor. It is also unclear whether TEDSS is required to follow 
Department of Defense (DoD) standards and comply with DoD Instruction 5200.28, 
Trusted Computing Systems Evaluation Criteria, informally called the ’Orange Book,’ by 
maintaining a specified security level. If TEDSS must meet specific security levels, this 
fact will drive many system choices and limit the ability to choose the best platform to 
support the EMT with commercially available hardware or software. For example, if 
TEDSS must comply with TEMPEST electronic emissions requirements, the number of 
portable computers which can serve as TEDSS platforms wiU be reduced dramatically 
whereas some storage technologies such as CD-ROM may be eliminated altogether from 
consideration. 
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G. SUMMARY 



This chapter has addressed major software issues that will affect TEDSS n initial 
and future usability. These include: NCS goals, long-term system growth, useability and 
adaptability, system maintenance, database administration, operating system capabilities, 
system stability, and security requirements. The following chapter will address TEDSS’ 
unique hardware requirements and emerging technology that may prove relevant to 
TEDSS n. 
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VI. OPERATIONAL CONSTRAINTS IN HARDWARE DEVELOPMENT 

Telecommunications Emergency Decision Support System (TEDSS) operational 
constraints restrict the hardware options available to assist the Emergency Management 
Team (EMT). The present deployable hardware is still usable, but it will not provide the 
support required to fully utilize the proposed system. 

TEDSS initial requirement for portability is not expected to change, but the method 
of satisfying this requirement should be decided primarily on management rather than 
technical grounds. The National Communications System (NCS) and the EMT must 
decide what mix of computing power and flexibility is desired to satisfy TEDSS hardware 
requirements. 

The movement of TEDSS from a textual orientation to a Graphical User Interface 
(GUI) will "involve a complete re-assessment of your system and your needs. Every 
item, from the hard disk drive to the display, will be affected by the change." 
(Nicholls, 1990, p.l64). Specifically TEDSS current internal gas-plasma monitor will not 
provide the high quality resolution needed in a GUI. TEDSS II’s increased use of 
graphics will require better video displays, increased data storage requirements, and 
alternate input devices. 

The following sections discuss the specific hardware issues related to the proposed 
TEDSS n and technologies that may offer future enhancement possibilities. 
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A. PORTABILITY 



The most powerful platform in terms of computing power, graphics capability, and 
future expendabUity is a workstation with an external large screen color monitor. 
However this power comes at the expense of a simple fly-away package that could be 
transported by the EMT. 

TEDSS primary mission to assist in emergencies requires that it be portable. 
However, the requirement for portability may be satisfied by several methods. The 
current TEDSS system is portable, but requires the relocation of three separate items: 
computer, external hard disk, and external monitor. The inability to move TEDSS as a 
single unit could be a deterrent to the efficient transportation of TEDSS and the 
mobilization of the EMT. 

Commercial portable computers may be categorized as either luggable or laptop. 
Luggable computers are self-contained with all components including the central 
processing unit, secondary storage devices and display, in one container which requires 
an external power supply to operate. The existing TEDSS Compaq Computer is an 
example of a luggable machine. A laptop computer provides the same functionality as 
the luggable, except with a physically smaller container and an internal power source. 

Luggable computers, because of their larger size and reduced concern for power 
consumption and space, often provide more powerful and capable computers than laptops. 
Additionally a luggable will allow a wider selection of other vendors’ hardware 
components which can be integrated. Portable computers often contain the stime 
components as a conventional personal computers (PC), however the efficient integration 
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of components and utilization of space result in a smaller footprint. Additionally video 
displays and keyboards will often be somewhat smaller and optimized for the specific 
portable computer. 

Laptop computers’ primary advantage is their reliance on internal power sources. 
While their internal batteries normally do not last longer than three hours, they free the 
user from the confines of a conventional office setting. Laptop computers generally 
weigh less than fifteen pounds and will contain the equivalent components as the 
luggable; however, they have all been optimized to decrease power consumption, space 
and weight requirements. Nearly all commercially available laptop computers use a 
Liquid Crystal Display (LCD). LCD monitors are noticeably inferior in screen quality, 
size and update speed to most other types of monitors. However, the LCD’s small power 
consumption makes them the only display type that can be supported by battery power 
for extended periods. Laptop computers have also optimized the keyboard to decrease 
its size with the result that a similar number of keys are fitted into less space and in 
different arrangements from conventional computer keyboards. This may require some 
user adjustment. 

It is generally a management, rather than a technical decision, whether the system 
should be AC powered or battery operated. Externally powered systems provide 
increased computing power which must be balanced against the need for ease in 
transportation. Additionally the total size of the unit must be addressed as well as its 
suitability to the crisis environment. Commercially available computer hardware can 
currently support TEDSS II regardless of the method selected to achieve portabOity. 
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Laptop computers will provide maximum utility to the EMT by allowing the system to 
be used in any location and without being constrained by AC power sources. However 
most laptops do not offer any internal expansion slots other than that for a modem. 

The NCS should evaluate its operational requirements with respect to how TEDSS 
will be utilized. Unless the environment for TEDSS is expected to change dramatically, 
a luggable computer will most likely provide improved support for future hardware 
growth. However, industry continues to release more powerful portable computers so it 
may soon be possible to find a laptop computer that supports many expansion 
opportunities. 

B. VIDEO ISSUES 

Using a GUI is much more demanding on the video section of the computer than 
on most other portions of the hardware. GUIs facilitate information transfer primarily 
through graphical icons, buttons, graphs and other visual cues. As the GUI screen will 
normally be displaying several items simultaneously, a GUI requires high resolution and 
better quality monitors with a larger physical viewing area to permit easier viewing. 
Grey-scale monitors, found in most laptop computers, will support GUIs but the 
additional use of color may improve the GUI’s usefulness. 

I. Color 

TEDSS will be more effective with color. Color increases the power of 
information presentation, but it is expensive and, at present, there is a limited selection 
of available color hardware options. While TEDSS II software could function using a 
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monochrome or grey-scale video display, the use of color will provide additional 
information to the EMT. For example, a grey-scale monitor would not be able to alert 
the user as effectively with blinking messages, since sharp contrast is not currently 
possible as with color monitors. 

Few laptop computers are available with color LCD or other type color 
displays. So far no technology has been developed to make a commercial color LCD 
monitor with acceptable power consumption. Presently, those portable computers with 
color monitors require an external AC power source. 

2. Video Resolution, Screen Size and Performance 

GUIs are best suited to large video monitors, and will tax the ability of the 
video portion to support objects being moved on the screen. Because GUIs allow 
multiple events to be happening concurrently, the monitor screen or ’desktop’ tends to 
become crowded. As in the office environment, if the screen becomes too crowded, 
worker performance will decline. The primary method of compensating for this effect in 
a GUI is to use higher screen resolution and a physically larger monitor. However as the 
screen size, or resolution, increases, the amount of information that must be updated and 
managed by the video portion increases as well. If no additional hardware is added, the 
overall video performance wUl deteriorate noticeably. 

TEDSS current VGA monitor operates at 640 by 480 pixels resolution, which 
is the highest resolution level supported by most portable computers. This resolution, 
while acceptable for a GUI with one application or window, may be found lacking after 
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users become more comfortable with the GUI and have multiple windows crowding the 



screen. 

The maximum resolution of a GUI is constrained by the hardware and video 
drivers rather than the GUI. For example X-Windows normally operates on 1280 by 
1024 pixel monitors, and the Macintosh operates on comparable resolutions. While 
higher resolution increases the amount of information which can be displayed, the relative 
size of the information is decreased, forcing a tradeoff between eye strain and amount of 
information. The only way to compensate for the size reduction of information is to 
physically increase the size of the screen. 

When given a choice, users will normally prefer a larger monitor, but if 
TEDSS must exist as a single unit for ease in deployment, the user interface must suffer. 
Laptop computers, and many luggables, use a nine inch video screen as measured 
diagonally, whereas most office computers use a thirteen or fourteen inch screen. 
However, graphic workstations will often use a nineteen inch monitor. TEDSS needs to 
consider alternatives to support other video systems than the one supplied with portable 
unit. 

LCD monitors in laptop computers, while normally acceptable for word 
processing and routine computer operations, may prove to be unacceptably slow and hard 
to view when using a GUI in TEDSS. The LCD method of lighting the screen results in 
slower screen updates, and is susceptible to contrast problems. For current LCD displays, 
"the response time (about 250 milliseconds) ... is not fast enough to display moving 
images on the screen." (Baron, 1991, p. 234). Tasks such as using pointing devices and 
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scrolling windows will be slowed by the screen update speed. The majority of LCDs use 
a "passive matrix design" which derive their power savings by lighting only the screen 
pixels that are required to show the letter or image. Because all pixels are not activated, 
unlike CRT monitors, laptops are susceptible to glare and contrast problems which further 
aggravate the difficulty in viewing moving objects on the screen. 

3. Video Considerations 

The quality of TEDSS video portion is critical to the effective use of a GUI, 
but if the system is not conducive to rapid relocation, the EMT may not be able to move 
the system quickly enough. The opposing requirements of a large screen which is 
portable will be difficult to attain with today’s technology. A middle ground must be 
reached to identify which requirement deserves more weight. An alternative to meet both 
requirements is installing hardware which will support two different monitors, one small 
monitor in the portable for immediate deployment, and a larger monitor which is deployed 
as soon as practical to the EMT. This option requires other hardware and software to 
support the use of different monitors. The portable computer must support an external 
video connection or allow an additional video card to be installed to drive the external 
monitor. 

C. EMERGING TECHNOLOGIES 

TEDSS should facilitate the addition of new technologies as appropriate. The 
emergency management environment is rapidly changing and the technology to support 
it wUl change also. Many commercial products in use today were not even imagined five 
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or ten years ago, and there is no reason to expect this to change. TEDSS should be in 
position to use other technology such as compact disk read-only memory (CD-ROM), 
write once read many (WORM) optical disks, hypertext, and other products that are 
evolving from the laboratory to the market place. Other existing office automation 
products such as networking, e-mail and voice mail support may become prudent 
additions to TEDSS as users become more sophisticated. To support the ability of 
TEDSS to evolve, initial components selected for TEDSS II should not lead to binding 
vendor relationships, but rather should rely as much as possible on open hardware and 
software standards. 

CD-ROM and WORM drive technology provide the ability to store and retrieve 
hundreds of megabytes of storage in a medium that is only a few square inches ins size 
and a few ounces in weight. TEDSS may be able to use CD-ROM to store all relevant 
emergency action documentation (EAD), maps, network operating manuals, and other 
voluminous information currently stored in paper form. By using hypertext or other 
methods to facilitate rapid retrieval, TEDSS could provide a ready emergency reference 
library for the EMT. 

Technologies that are in widespread use in office automation may fill important 
roles in TEDSS. If update and maintenance of data by the EMT becomes a bottleneck, 
a simple local area network to allow another user to remotely enter data in the command 
center may be an option. TEDSS could also provide increased telecommunications 
support for the EMT to include message transmission, storing and retrieving electronic 
mail, and other ’normal’ office automation tasks. 
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D. OTHER HARDWARE ISSUES 



This thesis addressed many of the major hardware and software issues relating to 
the redesign and update of TEDSS, however there are additional hardware issues that 
should be considered such as data security, electronic emissions, pointing devices, and 
output devices. 

Security requirements should be defined early in the TEDSS II redesign. Effective 
security is difficult to implement in a new program; it approaches a herculean task to 
implement after a system has been fielded. If TEDSS must meet TEMPEST or other 
security standards, this wUl most likely be the controlling factor in hardware procurement. 

GUIs rely heavily upon pointing devices. While most references have been to using 
a mouse as the pointing device, other vehicles may be better suited to the work 
environment of TEDSS. A trackball utilizes less space than a conventional mouse, while 
a pen or tablet system to enter information may be more natural to the users. Countless 
other pointing devices could be used effectively with TEDSS as weU. Once a pointing 
device is chosen, it should be standardized across the TEDSS implementation to prevent 
confronting the EMT with different devices in different regions. 

Several different methods of data input and retrieval have been addressed, however 
there has been no discussion of output devices. TEDSS would appear to have limited 
paper or hardcopy requirements but stUl should allow for the output of maps or text. 
Several small portable printers using bubble jet or impact printing methods provide 
acceptable output as well as portability. To augment any output devices which the EMT 
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deploys with TEDSS, the portable computer should be able to utilize laser printers and 
plotters that may be available at the control center. 
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Vn. RECOMMENDATIONS/CONCLUSIONS 



The goal of this thesis has been to assess the current state of Telecommunications 
Emergency Decision Support System (TEDSS), develop a vision for allowing TEDSS to 
better support emergency decision making by the Emergency Management Team (EMT), 
and to assess the major technological issues that should be considered in implementing 
this revised concept. 

TEDSS is in a critical time period in its system life. The current system marginally 
supports the EMT’s information management requirements, and does not significandy 
assist the EMT in effective decision making. To correct this deficiency, two paths may 
be taken; 

1. attempt to modify or improve incrementally upon the existing TEDSS design, or 

2. utilize the knowledge gained from the last eight years of TEDSS and develop a new 
conceptual paradigm for assisting the EMT. 

Choosing either path requires the knowledge and understanding of the NCS objectives for 
TEDSS. 

One of the serious problems in undertaking a redesign of TEDSS is that there is no 
specific set of requirements specifications which have been developed and documented. 
Since TEDSS carmot fulfill all roles equally well, the exact system goals must be 
determined. This thesis has attempted to provide a conceptual basis for a revised system 
without a complete knowledge of tliese objectives. At present there are no known dear 
cut goals of TEDSS beyond improving the emergency decision making process. Since 



74 



I have not been privy to a full utilization session with TEDSS because of security 
restrictions, it is important to note that these recommendations must be evaluated with 
early and consistent user involvement to ensure a viable and useful product is developed. 

It is recommended that the TEDSS orientation be shifted from textual to graphical 
using the Tactical Decision Aid (TDA) concept. Graphical presentations will assist the 
EMT in rapidly assimilating changing information. The TDA recognizes that information 
about the decision environment is constantly changing and assists the user in 
compensating for this dynamic situation by allowing simulations that provide projections 
of the results of decisions. The new model of TEDSS II changes the system from a data 
bcise oriented system to a graphics system in which the user’s primary communication 
method is the moving and modification of graphical images rather than text. 

The primary TEDSS II interface will be a graphical user interface (GUI) coupled 
with a geogr^hic information system (GIS). Data will stUl be stored in a data base, but 
its retrieval and query generation will be done through menu selections and highlighting 
of map areas. TEDSS II will use the EMT conceptual model of the emergency area by 
displaying information on maps with the use of colorations and icons to increase 
information transferal and represent spatial relationships. 

It is recognized that TEDSS cannot anticipate or facilitate every decision, therefore 
the user should be allowed access to data through a Stmctured Query Language (SQL) 
interface to the data base. This accommodates ad hoc queries which TEDSS currently 
does not support directly. 
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The framework outlined for TEDSS II will support many implementation options. 
By using a GUI as the primary user interface, training should be enhanced by providing 
standard a menu structure. Additional components may be added without a commensurate 
increase in training. Support for missions such as hurricane, earthquake and other natural 
disasters affecting communications systems may be facilitated by additional damage 
assessment models to augment the present nuclear model. Previous efforts on the Expert 
Telecommunications Resource Allocation Model (XTRAM) could also be incorporated 
into the model base. 

TEDSS should be considered as a prototype which is subject to continuous 
development and change to support the dynamic decision environment in which it 
operates. To facilitate that goal of adapting to change, extra attention must be placed on 
the requirement assessment phases during initial and future upgrades. The EMT is a 
skilled, interested core of users that will ultimately determine the final utility of TEDSS 
II. Methodologies such as storyboarding to map out the current and future requirements 
of TEDSS, will assist in validating and verifying requirements during development as well 
as to identify system deficiencies early in the process. 

The quality of decision support provided by TEDSS wUl ultimately be decided by 
the quality, relevance and accuracy of information in the form of data and models which 
it can access. The dependence of TEDSS on external sources of information is unlikely 
to change, but the access to external data sources should be defined. Use of proprietary 
commercial carrier information would undoubtedly increase the quality of support given 
by TEDSS, while its absence will be detrimental. 
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The concept of TEDSS as a TDA is more in keeping with the true mission of the 
NCS and its role of emergency management. A TDA-based information system has 
architectural and design ramifications which differ dramatically from the current database- 
oriented concept of TEDSS. 

The emphasis on graphics will tax TEDSS hardware differently. The GUI and GIS 
require a powerful video display system to facilitate the graphical presentation of data. 
The GUI’s ability to use several system resources in separate windows requires TEDSS 
to support multi-tasking. While the GUI frees the user to explore different screen 
arrangements, it also requires that TEDSS applications be implemented in conformance 
with GUI conventions to prevent reducing the GUI’s overall effectiveness. 

Furthermore TEDSS II will ultimately alter the EMT’s basic use of TEDSS by 
moving from a text interface to an interface using graphics, pointing devices, and voice. 
As the system and the users mature, TEDSS II should become an increasingly powerful 
decision aid which can enhance the ability to make quality decisions in a multitude of 
emergency environments. 
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